2021年7~9月のMAD事業部メンバーのOSSコントリビュートについてご紹介します

2021年7~9月のMAD事業部メンバーのOSSコントリビュートについてご紹介します

Clock Icon2021.10.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

CX事業本部@大阪の岩田です。私の所属するMAD事業部では今期からKPIの1つとしてOSSへのコントリビュート数をカウントする試みがスタートしました。我々の仕事にはOSSが欠かせませんが、単に利用するだけではなくissueを報告したり、場合によってはプルリクエストを作成したり...といった形で大小様々な形でコントリビュートしています。このコントリビュート数や内容を部署として記録することで、自分たちが世の中の役に立っているという自信やモチベーションにつながりますし、普段プロジェクトで直接関わらない他のメンバーがどういった活動をしているのか、部署のメンバーのことを知る良い機会にもなります。

せっかくなので、他部署メンバーへの紹介も兼ねて弊社の第1Qである7月~9月における各メンバーのコントリビュート実績を紹介してみます。

OSSコントリビュート実績一覧

以下が各メンバーによるコントリビュート実績です。マージされていないプルリクエストも含めています

Pipenvがinstallやsyncを実行する際に環境変数PIP_TARGETを考慮するように修正

がプロジェクトでも利用しているPipenvにコントリビュートしたものです

以前こちらの記事でも紹介したのですが、ローカルの開発環境からLambdaレイヤーをデプロイする際に

  • ローカル開発環境にはテスト用のライブラリをインストールしたい
  • AWS環境にデプロイするレイヤーからはテスト用のライブラリを除外したい

ということはよくあるニーズだと思います。

このニーズに対応するためにpipenv利用時にPIP_TARGETという環境変数を指定することで、レイヤーデプロイ用のライブラリ群のインストール先を指定する方法を紹介していたのですが、PipenvのバージョンRelease v2020.4.1b2からはこのテクニックが期待した動作をしなくなりました。このバージョンから指定されたライブラリが既にインストール済みの場合はインストール処理をスキップする処理が追加されているのですが、このチェック処理が環境変数PIP_TARGETを考慮してくれないのです。つまり環境変数PIP_TARGETlayersという空のディレクトリを指定してpipenv installpipenv syncした場合でも、デフォルトのライブラリインストール先に対象ライブラリがインストール済みの場合はlayersディレクトリへのインストールがスキップされてします。

この問題を報告しつつ、指定されたライブラリがインストール済みかをチェックする処理でも環境変数PIP_TARGETを参照するように修正したのがこちらのissue & プルリクエストです。

まだマージされていないので、+1して頂けるとうれしいです。

Amazon Athena Lambda Jdbc Connectorデプロイ用SAMテンプレートのjarファイル指定誤りを修正

こちらも私が上げたプルリクエストです。AthenaからLambda & JDBCドライバを介して各種DBにアクセスするためのコネクタをデプロイするためのテンプレートファイルで指定しているjarファイルのバージョンが更新されておらず、古いバージョンが指定されていました。これによりjarファイルをビルドしてもLambdaがデプロイできない状態となっていました。

https://github.com/awslabs/aws-athena-query-federation/pull/435

実はJDBCドライバ以外のコネクタにも同様の問題があったので、私のプルリクエストはcloseされ、メンテナによる別のプルリクエストにて全コネクタのバージョン指定が修正&マージされています。

CDKにAurora Postgres engine10.16と11.11のサポート追加

もこによるCDKへのコントリビュートです。2021年6月のアップデートにてAmazon AuroraがPostgreSQL10.16と11.11をサポートするようになりました

このアップデートにCDKを追随させたという内容です。

https://github.com/aws/aws-cdk/pull/15781

CDKのecs-patternsモジュールのQueue Processing ServicesにcapacityProviderStrategiesのサポートを追加

同じくCDKへのコントリビュートです。こちらは大澤によるCDK初コントリビュートになります。L3コンストラクタのQueue Processing Servicesでキャパシティプロバイダーを利用したいというissueが上がっており、こちらを実装した形になります。

https://github.com/aws/aws-cdk/pull/15684

KMSワークショップのドキュメントの不備を修正

加藤によるAWS KMS Workshopへのコントリビュートです。

ドキュメントに記載されているIAMポリシーが誤っていたため、正しいポリシー名に修正するプルリクエストを上げています。

https://github.com/aws-samples/aws-kms-workshop/pull/2

これでドキュメントの手順通りに進めたのに何故かうまくいかない...と悩まされる人がいなくなるはずなのですが、こちらもまだマージされていないので、+1して頂けると嬉しいです。

motoのAWS IoTをモックするクラスにIoTポリシーの最大バージョン数超過の例外を実装

AWSのサービスをモックしてくれるPythonのライブラリmotoに小倉がコントリビュートしたものです。AWS IoTのポリシーのバージョンは最大5つに制限されており、6つ目のバージョンを作成しようとするとエラーになるのですが、motoに実装されているAWS IoTのモッククラスは6つ以上のバージョンが作成できる実装となっており、実際のAWS IoTの振る舞い通りになっていませんでした。

このプルリクエストによって6つ以上のバージョンを作成しようとするとVersionsLimitExceededExceptionがraiseされるようになり、実際のAWS IoT & boto3と同様の振る舞いをしてくれるようになりました。これでバージョン数超過の例外をキャッチして何らかの処理をするようなコードのユニットテストがしやすくなりました。

https://github.com/spulec/moto/pull/4173

ent.のIntegrationテストが通らなくなっていたのを修正

新井が以前ブログにもしていたGo言語のエンティティフレームワークentにコントリビュートしたものです。

Integrationテストが通らなくなっていたのでissueを起票しつつ、Dockerイメージのバージョンを固定することで問題を回避するプルリクエストを作成&マージされています。メンテナと英語で色々とやりとりをしているのがカッコ良いですね。

ent.のORMに機能拡張を提案

同じく新井によるent.のコントリビュートです。こちらはドラフトプルリクエストという形で機能拡張を提案しています。Gremlinのクエリをより便利に使えるような提案です。

https://github.com/ent/ent/pull/1792

まとめ

MAD事業部メンバーによるコントリビュート実績でした。マージされていないプルリクエストであっても、何かしらの形でプロジェクトに貢献できているはずなので、コントリビュート実績としてカウントしています。今回紹介した個々の内容自体は簡単なものが多いですが、OSSにコントリビュートするには何か複雑な機能を実装しないといけないとか、難しいバグを修正しないといけない といったルールはありません。ドキュメントのタイポを1文字修正するだけでも立派なコントリビュートになるので、これまでコントリビュートしたことがない人の心理的障壁を下げたいという意図もあって内容の大小に関わらずに全て紹介しています。

今後も継続的にOSSにコントリビュートしながら、定期的に実績を紹介していければと思います。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.